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1 (4) REMARKS 

2 RESPONSE TO REJECTION UNDER SEC. 1 03 

3 All pending claims (1-7) are rejected under 35 U.S.C. Sec. 103 as obvious in view of a single 

4 reference, U.S. Pat. No. 6,263,369 (Sitaraman) in view of U.S. Pat. No. 6,128,648 (Chen). The 

5 Action mistakenly cites Pat. No. 6,236,369 versus the con-ect PTO-849 citation. 

6 Applicant is of the opinion that the Office's contentions regarding the primary reference 

7 Sitaraman are misinterpretations of that description when it is considered in accordance with its 

8 own language rather than mere analogized to applicants claims as in para. 4 of the Action. 

9. Chen is only relied upon for disclosing, "...that the server updated the local cache with discard 

10 ' cache content of local cache, see (col. 1, lines 46-65). Action Page 3, about lines 12-19. 

11 In general, it must be noted that Sitaraman's technology is related to an Internet Service 

12 Provider (ISP) allowing customers to access the Intemet from any of the ISP's Points of 

13 Presence (PoP). For example, a customer of an ISP who lives in Washington D.C. would 

14 normally dial via a local modem call, not long distance charged connection, into the local PoP. 

15 When the user is traveling, e.g., to Philadelphia, via Sitaraman's scheme they are now allowed 

16 to dial the local number for the Philadelphia PoP and get connected to the Internet. Other than 

17 possibly using a different number to connect, the user doesn't have to do anything different. 

18 The scheme Sitaraman uses is to keep a record on each of the ISP's customers. Each of these 

19 record is assigned to exactly one access point - - see elements 76, 78 or 80 in FIG. 2 of 

20 Sitaraman. Before a user can connect, the system checks that the user is an ISP customer; if 

21 none is found, the mother cache is contacted to see if the customer is roaming - - that is, 

22 assigned to the D.C. PoP but dialing the Philadelphia PoP. If a user record is then found in the 

23 mother cache, a link is allowed; if not access is denied. 

24 This is different both in fact and in function, way, and result from the present invention. 
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1 (1) In re Claim 1: In Sitaraman. an ISP environment, assigning each user to exactly one 

2 local cache may be logical since users will typically dial in from the same location most 

3 of the time. This is not logical for Web caching as any user on the Internet could request 

4 a particular file. Thus a file would have to be stored in any of the N caches in the 

5 system. In Sitaraman's scheme, a particular user record must be stored in only two 

6 caches, the mother cache and the local cache that the user's record is assigned to, 

7 namely the corresponding cache of a user record. If a user from access point 76 is 

8 roaming and dials in at access point 80, their user record will be retrieved from the 

9 mother cache, but will not be stored in the local cache 98 of access point 80 since the 

10 local cache 84 of access point 76 is the only local cache allowed to store that record. 

1 1 Compare this to the present invention as claimed where a file can be stored in any local 

12 cache. The present invention thus is defined to handle situations where a file is stored 

13 ' in N different local caches. Moreover, a file can not only be stored in any of the N 

14 caches, but also can appear in all N caches simultaneously. Sitaraman cannot handle 

15 either of these cases. This is not handled by the invalidation policy in Sitaraman, col. 7, 

16 line 45-48. 

17 (2) The present invention has an advantage of minimizing the number of times the origin 

18 server must be contacted, improving scalability of the system. For example, consider a 

19 file in a proxy cache that is under lease. No invalidation message is received. The 

20 present invention can handle all user requests for this file without any communication 

21 with the origin server whatsoever. In Sitaraman, there are at least three messages sent 

22 to the mother cache as a result of every access; an address allocated event, see 

23 element 236 FIG. 4, an accounting start event, see element 242; and an accounting stop 

24 event, see element 246. Now, in addition, if the user is roaming, the mother cache must 

25 be contacted to retrieve the user's record; also, the local cache for the access point the 

26 user nonnally connects to must be updated. Note Sitaraman at col. 7, line 9-13 

27 indicates that the "...mother cache must receive all network access events...". This is 

28 not scalable to high access rates needed for Web site access which are several orders 

29 of magnitude higher than connection access rates. 
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1 (3) In re Claim 2 and 3: Since each us r's record in Sitaraman is assigned to a specific 

2 local cache, the local cache does not have to notify the mother cache of its intention to 

3 act as an authoritative server for that record. That is, there is no subscription as 

4 described and claimed in the present application. All other local caches never cache 

5 that particular user record, so they do not have to subscribe either Each file could 

6 potentially be located simultaneously in all N caches; this is never the case in Sitaraman. 

7 (4) In re Claim 4: In Sitaraman, since each user's record is assigned to a specific local 

8 cache, it will not be removed form the cache if the user simply does not dial in on a 

9 predetermined schedule. There is no notion of popularity of this kind of file considered 
10. when deciding which records to keep in a local cache. 

11 (5) In re Claims 5, 6 and 7: The Sitaraman system sends out updated messages, but only 

12 because each user record is assigned to only a single local cache; all other (-1) local 

13 caches can simply ignore the message. See Col. 7, lines 45-48. The present invention 

14 can handle more than one, up to N, caches containing a file, thus requiring more 

15 sophisticated techniques to ensure cache consistency is maintained, and without 

16 inadvertently affecting scalability. 

17 (6) In re Claim 4: In Sitaraman, user records are assigned to exactly one local cache on a 

18 "permanent" basis (unless the local cache crashes and has to be restored from the 

19 mother cache). There is no leasing mechanism. The present invention describes a 

20 leasing mechanism to ensure scalability of the system which can potentially have copies 

21 of a file simultaneously at all N caches. 

22 (7) In re Claims 4, 5, 6, and 7: In Sitaraman. the local cache where the user record is 

23 assigned is "permanent," so they never have to discard inactive records. Since the 

24 number of users is known, and the size of each record is likely the same, it is easy for 

25 the ISP to determine how many local caches are needed to support all of their users. In 
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1 the present invention, a mechanism for r moving unpopular cont nt is provided to store 

2 more popular content. Again, scalability is improved. 

3 IN RE CHEN 

4 Chen discusses invalidation techniques for mobile users who may disconnect from the network. 

5 Such users typically preload their cache from the server prior to disconnecting from the server's 

6 network. Since the content may be changed at the server, and the server has no method of 

7 communicating with a disconnected user, the user may now view invalid content. Thus, that 

8 user could not serve as an authoritative server for the original server. This is a capability in the 

9 present application when caches stay connected. 

10 * In accordance with the Office's allegation, a combination of Sitaraman with Chen at best only 

1 1 results in an access link method in which after the user breaks the link, the local, in the e.g., 

12 Philadelphia, file records of the roaming D.C. user are discarded. This has nothing to do with 

13 the present invention as described and claimed. 

14 It is respectfully requested that the rejections be withdrawn. 

15 LEGAL ARGUMENT RESPONSE 

16 The undersigned is informed and believes that this is the fourth Action. Previously cited Inohara 

17 et al. and DeSimone et al. have apparently be retracted. The Office accepts, at least tacitly, 

18 applicants' prior submitted arguments submitted by the undersigned against previously cited 

19 Krishnan (see second Office Action), mailed Feb. 18, 2003, and applicants' arguments against 

20 previously cited Heddaya (see second Office Action), mailed June 12, 2003. In this third Action, 

21 the Office cites two new references, Sitaraman and Chen. 

22 The law is clear. Hindsight reasoning using the invention for which a patent is sought as a 

23 template is impemiissible. Texas Instruments. Inc. v. ITC . 26 USPQ2d 1018 (CA FC 1993). 
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1 It would appear from this file wrapper history that the Office is in fact not keeping to the spirit of 

2 Texas Instruments. Each Action evidences a progressively seeking of new references based 

3 on the present invention and attempting to force fit similar language of references into 

4 applicants' mold based on the application and the prior arguments. This alone is hindsight. 

5 Moreover, the very practice of structuring grounds for rejection by repeating applicants' claim 

6 language and then sticking column and line citations of a reference therein is de facto use of the 

7 application as a "template." 

8 With respect to any further rejections which may issue against this application, unless a citation 

9 to column/line(s) of a reference is an exactly identical element to the present application where 
10 there can be no ambiguity as to identity of actual structure, function, way and result - - e.g., 

ii. where a claim element is a "computer keyboard" and the reference "col. 10: II. 10" has a 

12 ' "computer keyboard" -- applicants' respectfully request that each further rejections quote the 

13 specific language from the reference alleged to equate to each claimed element so rejected. In 

14 this manner the applicant will not be required to infer from a simple cite of "col. N: line what 

15 the Office is arguing. 

16 It is respectfully requested that the rejections be withdrawn on this ground. 

17 SUMMARY AND CONCLUSION 

18 Sitaraman was not worthing on the problem of Web caching which the present invention 

19 addresses, Sitaraman fails to stand for the propositions asserted by the Office; it does not 

20 provide the same functionality of the present invention, and is in fact by its own tenms vastly 

21 different from applicant's disclosed invention and in some instances clearly contrary to 

22 applicant's disclosed invention. Therefore, it is not a suited reference on which to base an 

23 objection of obviousness. 

24 Based upon the foregoing, it is submitted that the application now presents claims which are 

25 directed to novel, unobvious and distinct features of the present invention which are an 
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advancement to the state of the art. Reconsideration and allowance of all claims is resp ctfully 
requested. The right is expressly reserved to reassert any and all arguments, including the 
raising of new arguments, should a Notice of Allowance not be forthcoming. 

Questions or suggestions that will advance the case to allowance may be directed to the 
undersigned by teleconference at the Examiner's convenience. 

Date: fiiJ^l . 6^ ^ Ql^p^ ^ Respectfully submitted, / 
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